Интересная и полезная штука обнаружилась на одном из блогов, посвященных технологиям виртуализации - утилита VMware ESXi SCSI Sense Codes Decoder. Она позволяет декодировать сообщения, появляющиеся в файле журнала vmkernel.log, когда что-то идет не так при работе хост-сервера ESXi с хранилищами по протоколу блочного доступа SCSI.
Например, вы видите вот такое сообщение:
2011-04-04T21:07:30.257Z cpu2:2050)ScsiDeviceIO: 2315: Cmd(0x4124003edb00) 0x12, CmdSN 0x51 to dev “naa.[…]” failed H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x24 0x0.
Это, на самом деле, 6 статус-кодов (они выделены жирным выше), которые можно разложить следующим образом, подставив значения в форму ESXi SCSI Sense Codes Decoder:
В качестве результата вы получите расшифровку статус-кодов SCSI, которая поможет вам в решении той или иной проблемы:
Пользоваться утилитой ESXi SCSI Sense Codes Decoder можно только онлайн.
Некоторые из вас знают, что для поиска и решения проблем в виртуальной инфраструктуры, среди прочих интерфейсов командной строки, есть такой инструмент, как Ruby vSphere Console (RVC).
Используется она достаточно редко, но ниже мы покажем пример ее использования на базе вот этой заметки от Кормака Хогана.
Чтобы запустить Ruby vSphere Console, нужно набрать в командной строке ESXi команду в следующем формате:
rvc [options] [username[:password]@]hostname
Например:
# rvc administrator:vmware@192.168.1.100
После этого появится приглашение ко вводу различных команд:
login as: root
VMware vCenter Server Appliance
administrator@192.168.1.100's password:
Last login: Thu Jul 17 22:29:15 UTC 2014 from 10.113.230.172 on ssh
Last failed login: Fri Jul 18 06:31:16 UTC 2014 from 192.168.1.20 on ssh:notty
There was 1 failed login attempt since the last successful login.
Last login: Fri Jul 18 06:31:35 2014 from 192.168.1.20
vcsa:~ # rvc administrator:vmware@192.168.1.100
0 /
1 192.168.1.100/
Их можно выполнять в рамках следующих пространств имен (namespaces):
Во второй снизу строчке мы видим пространство имен VSAN, относящееся к кластерам хранилищ Virtual SAN. Давайте посмотрим на решение одной проблемки с его помощью.
Допустим, вы увидели в кластере VSAN следующую ошибку в разделе Component Metadata Health:
Invalid state
Согласно вот этой статье KB 2108690, эта ошибка может относиться к физической проблеме с диском - когда процесс выделения физических блоков при сбрасывании их из кэша на диск идет очень медленно. Эта ошибка может свидетельствовать просто о высокой нагрузке на диск, в этом случае она уходит при спаде нагрузки. Но если она повторяется при малой нагрузке - значит с диском явно что-то не так.
В столбце "Component" указан component UUID диска, с которым возникла проблема - но как узнать, на каком хранилище он расположен, в консоли vSphere Web Client? Для этого мы и возьмем Ruby vSphere Console, а именно команду vsan.cmmds_find:
Вчера мы писали о новых возможностях, появившихся в обновленной версии платформы виртуализации VMware vSphere 6.0 Update 2, однако не упомянули интересную деталь, которая важна для пользователей в крупных инфраструктурах.
Когда хост VMware ESXi входит в режим обслуживания (Maintenance Mode), происходит следующее: все виртуальные машины на хосте перемещаются ("эвакуируются") на другие хост-серверы ESXi для того, чтобы по окончании процесса временно вывести хост из состава виртуальной инфраструктуры для манипуляций с ним, без остановки сервисов в виртуальных машинах.
Но суть улучшения Update 2 состоит в следующем. До этого релиза сначала происходила миграция запущенных виртуальных машин, которая занимала несколько минут и более, в зависимости от нагрузки на них. Затем уже происходила миграция выключенных машин и шаблонов ВМ (VM Templates), перенести которые занимает несколько секунд (просто перерегистрировать их на других хостах).
Однако при вхождении хоста в Maintenance Mode операции с его объектами (в том числе шаблонами) недоступны, а значит сервисы, задействовавшие клонирование ВМ из шаблона (например, VMware View или vCloud Director), также не могут исполнять свои функции, и пользователям придется ожидать окончания процесса.
Ну а в Update 2 просто поменяли местами порядок переноса - сначала мигрируют выключенные ВМ и шаблоны, что позволяет использовать их уже через несколько секунд, а только потом переезжают включенные виртуальные машины. Это иллюстрируется простой и понятной картинкой:
Интересную новость мы обнаружили вот тут. Оказывается утилита esxtop может работать в режиме повтора для визуализации данных о производительности, собранных в определенный период времени (многие администраторы знают это, но далеко не все). Это позволит вам собрать данные о производительности хоста, например, ночью, а в течение рабочего дня проанализировать аномальное поведение виртуальной инфраструктуры VMware vSphere. Называется этот режим replay mode.
Для начала запустите следующую команду для сбора данных на хосте VMware ESXi:
Иногда системному администратору VMware vSphere требуется узнать, сколько тот или иной хост ESXi работает с момента последней загрузки (например, требуется проверить, не было ли внеплановых ребутов).
Есть аж целых 5 способов сделать это, каждый из них можно применять в зависимости от ситуации.
1. Самый простой - команда uptime.
Просто заходим на хост ESXi из консоли или по SSH и выполняем команду uptime:
login as: root
Using keyboard-interactive authentication.
Password: XXXXXX
The time and date of this login have been sent to the system logs.
VMware offers supported, powerful system administration tools. Please
see www.vmware.com/go/sysadmintools for details.
The ESXi Shell can be disabled by an administrative user. See the
vSphere Security documentation for more information.
~ # uptime
04:26:24 up 00:20:42, load average: 0.01, 0.01, 0.01
2. С помощью команды esxtop.
С помощью утилиты esxtop можно не только отслеживать производительность хоста в различных аспектах, но и узнать его аптайм. Обратите внимание на самую первую строчку вывода:
# esxtop
4. Время запуска хоста из лога vmksummary.log.
Вы можете посмотреть не только время текущего аптайма хоста ESXi, но времена его прошлых запусков в логе vmksummary.log. Для этого выполните следующую команду:
cat /var/log/vmksummary.log |grep booted
2015-06-26T06:25:27Z bootstop: Host has booted
2015-06-26T06:47:23Z bootstop: Host has booted
2015-06-26T06:58:19Z bootstop: Host has booted
2015-06-26T07:05:26Z bootstop: Host has booted
2015-06-26T07:09:50Z bootstop: Host has booted
2015-07-08T05:32:17Z bootstop: Host has booted
4. Аптайм в vSphere Client и Web Client.
Если вы хотите вывести аптайм сразу всех виртуальных машин на хосте в VMware vSphere Client, для этого есть специальная колонка в представлении Hosts:
5. Аптайм хостов через PowerCLI.
Конечно же, время работы хоста ESXi можно посмотреть и через интерфейс PowerCLI. Для этого нужно воспользоваться командлетом Get-VMHost:
Если вы посмотрите в документ VSAN Troubleshooting Reference Manual (кстати, очень нужный и полезный), описывающий решение проблем в отказоустойчивом кластере VMware Virtual SAN, то обнаружите там такую расширенную настройку, как VSAN.ClomMaxComponentSizeGB.
Когда кластер VSAN хранит объекты с данными виртуальных дисков машин, он разбивает их на кусочки, растущие по мере наполнения (тонкие диски) до размера, указанного в данном параметре. По умолчанию он равен 255 ГБ, и это значит, что если у вас физические диски дают полезную емкость меньше данного объема (а точнее самый маленький из дисков в группе), то при достижении тонким диском объекта предела физической емкости вы получите вот такое сообщение:
There is no more space for virtual disk XX. You might be able to continue this session by freeing disk space on the relevant volume and clicking retry.
Если, например, у вас физический диск на 200 ГБ, а параметры FTT и SW равны единице, то максимально объект виртуального диска машины вырастет до этого размера и выдаст ошибку. В этом случае имеет смысл выставить настройку VSAN.ClomMaxComponentSizeGB на уровне не более 80% емкости физического диска (то есть, в рассмотренном случае 160 ГБ). Настройку эту нужно будет применить на каждом из хостов кластера Virtual SAN.
Как это сделать (более подробно об этом - в KB 2080503):
В vSphere Web Client идем на вкладку Manage и кликаем на Settings.
Под категорией System нажимаем Advanced System Settings.
Выбираем элемент VSAN.ClomMaxComponentSizeGB и нажимаем иконку Edit.
Устанавливаем нужное значение.
Надо отметить, что изменение этой настройки работает только для кластера VSAN без развернутых на нем виртуальных машин. Если же у вас уже продакшен-инфраструктура столкнулась с такими трудностями, то вы можете воспользоваться следующими двумя способами для обхода описанной проблемы:
1. Задать Object Space Reservation в политике хранения (VM Storage Policy) таким образом, чтобы дисковое пространство под объекты резервировалось сразу (на уровне 100%). И тогда VMDK-диски будут аллоцироваться целиком и распределяться по физическим носителям по мере необходимости.
2. Задать параметр Stripe Width в политиках VM Storage Policy таким образом, чтобы объекты VMDK распределялись сразу по нескольким физическим накопителям.
Фишка еще в том, что параметрVSAN.ClomMaxComponentSizeGB не может быть выставлен в значение, меньшее чем 180 ГБ, а значит если у вас носители меньшего размера (например, All-Flash конфигурация с дисками меньше чем 200 ГБ) - придется воспользоваться одним из этих двух способов, чтобы избежать описанной ошибки. Для флеш-дисков 200 ГБ установка значения в 180 ГБ будет ок, несмотря на то, что это уже 90% физической емкости.
Продолжаем рассказывать о лучшем решении для создания отказоустойчивых программных хранилищ StarWind Virtual SAN, предназначенном для создания и поддержки инфраструктуры виртуальных машин на платформах VMware vSphere и Microsoft Hyper-V. В этом посте мы расскажем о том, как поменять дефолтные порты решения Virtual SAN, так как это один из самых часто задаваемых вопросов по продукту.
По умолчанию StarWind Virtual SAN использует порты 3260 и 3261 для взаимодействия виртуальных машин с программными хранилищами. Порт 3260 используется для передачи данных от ВМ к хранилищам и обратно. Однако этот порт, зачастую, оказывается занятыми программной реализацией iSCSI от компании Microsoft, если до этого на сервере использовался данный механизм.
В этом случае при развертывании StarWind Virtual SAN имеет смысл настроить другой порт вместо 3260. Делается это следующим образом:
1. Открываем папку с решением StarWind, по умолчанию это C:\Program Files\StarWind Software\StarWind.
2. Ищем файл StarWind.cfg и открываем его.
3. Находим значение параметра <Port value="3260"/>, меняем его на нужное и сохраняем файл.
4. Перезапускаем службы StarWind на сервере для применения изменений.
Ну или в качестве альтернативного способа можете отключить службы MS iSCSI Target.
Не так давно мы писали о полезном дэшборде для продукта VMware vRealize Operations, а сегодня расскажем, как восстановить забытый пароль от виртуального модуля vRealize Operations 6.x (vROPs).
Если вы не помните пароль, нужно просто перезагрузить Virtual Appliance и в меню загрузки в раздел Boot Options добавить после всех параметров следующую строчку:
init=/bin/bash
Далее загружаемся в консоль и просто пишем:
# passwd
После этого у нас запросят создать новый пароль пользователя root, далее перезагружаем модуль командой:
# reboot
Затем неплохо бы включить сервис SSH управлять модулем уже через putty:
Чтобы SSH работал постоянно, нужно выполнить команду:
# chkconfig sshd on
Обратите внимание, что это не только способ восстановить/сбросить пароль на vROPs, но и большая дыра в безопасности, так как любой, кто имеет доступ к консоли модуля, может провернуть это.
На блоге vSphere появилась отличная статья о сервисах семейства vCenter Server Watchdog, которые обеспечивают мониторинг состояния различных компонентов vCenter, а также их восстановление в случае сбоев. Более подробно о них также можно прочитать в VMware vCenter Server 6.0 Availability Guide.
Итак, сервисы Watchdog бывают двух типов:
PID Watchdog - мониторит процессы, запущенные на vCenter Server.
API Watchdog - использует vSphere API для мониторинга функциональности vCenter Server.
Сервисы Watchdog пытаются рестартовать службы vCenter в случае их сбоя, а если это не помогает, то механизм VMware перезагружает виртуальную машину с сервером vCenter на другом хосте ESXi.
PID Watchdog
Эти службы инициализируются во время инициализации самого vCenter. Они мониторят только службы, которые активно работают, и если вы вручную остановили службу vCenter, поднимать он ее не будет. Службы PID Watchdog, контролируют только лишь наличие запущенных процессов, но не гарантируют, что они будут обслуживать запросы (например, vSphere Web Client будет обрабатывать подключения) - этим занимается API Watchdog.
Вот какие сервисы PID Watchdog бывают:
vmware-watchdog - этот watchdog обнаруживает сбои и перезапускает все не-Java службы на сервере vCenter Server Appliance (VCSA).
Java Service Wrapper - этот watchdog обрабатывает сбои всех Java-служб на VCSA и в ОС Windows.
Likewise Service Manager - данный watchdog отвечает за обработку отказов всех не-Java служб сервисов platform services.
Windows Service Control Manager - отвечает за обработку отказов всех не-Java служб на Windows.
vmware-watchdog
Это шелл-скрипт (/usr/bin/watchdog), который располагается на виртуальном модуле VCSA. Давайте посмотрим на его запущенные процессы:
Давайте разберем эти параметры на примере наиболее важной службы VPXD:
-a
-s vpxd
-u 3600
-q 2
Это означает, что:
vpxd (-s vpxd) запущен (started), для него работает мониторинг, и он будет перезапущен максимум дважды в случае сбоя (-q 2). Если это не удастся в третий раз при минимальном аптайме 1 час (-u 3600 - число секунд), виртуальная машина будет перезагружена (-a).
Он основан на Tanuki Java Service Wrapper и нужен, чтобы обнаруживать сбои в Java-службах vCenter (как обычного, так и виртуального модуля vCSA). Вот какие службы мониторятся:
Если Java-приложение или JVM (Java Virtual Machine) падает, то перезапускается JVM и приложение.
Likewise Service Manager
Это сторонние средства Likewise Open stack от компании BeyondTrust, которые мониторят доступность следующих служб, относящихся к Platform Services среды vCenter:
VMware Directory Service (vmdir)
VMware Authentication Framework (vmafd, который содержит хранилище сертификатов VMware Endpoint Certificate Store, VECS)
VMware Certificate Authority (vmca)
Likewise Service Manager следит за этими сервисами и перезапускает их в случае сбоя или если они вываливаются.
mgmt01vc01.sddc.local:~ # /opt/likewise/bin/lwsm list | grep vm vmafd running (standalone: 5505) vmca running (standalone: 5560) vmdir running (standalone: 5600)
Вместо параметра list можно также использовать start и stop, которые помогут в случае, если одна из этих служб начнет подглючивать. Вот полный список параметров Likewise Service Manager:
list List all known services and their status autostart Start all services configured for autostart start-only <service> Start a service start <service> Start a service and all dependencies stop-only <service> Stop a service stop <service> Stop a service and all running dependents restart <service> Restart a service and all running dependents refresh <service> Refresh service's configuration proxy <service> Act as a proxy process for a service info <service> Get information about a service status <service> Get the status of a service gdb <service> Attach gdb to the specified running service
А вот таким образом можно узнать детальную информацию об одном из сервисов:
Помните также, что Likewise Service Manager отслеживает связи служб и гасит/поднимает связанные службы в случае необходимости.
API Watchdog
Этот сервис следит через vSphere API за доступностью самого важного сервиса vCenter - VPXD. В случае сбоя, этот сервис постарается 2 раза перезапустить VPXD, и если это не получится - он вызовет процедуру перезапуска виртуальной машины механизмом VMware HA.
Эти службы инициализируются только после первой загрузки после развертывания или обновления сервисов vCenter. Затем каждые 5 минут через vSphere API происходит аутентификация и опрос свойства rootFolder для корневой папки в окружении vCenter.
Далее работает следующий алгоритм обработки отказов:
Первый отказ = Restart Service
Второй отказ = Restart Service
Третий отказ = Reboot Virtual Machine
Сброс счетчика отказов происходит через 1 час (3600 секунд)
Перед рестартом сервиса VPXD, а также перед перезагрузкой виртуальной машины, служба API Watchdog генерирует лог, который можно исследовать для решения проблем:
storage/core/*.tgz - на виртуальном модуле VCSA
C:\ProgramData\VMware\vCenterServer\data\core\*.tgz - не сервере vCenter
Конфигурация сервиса API Watchdog (который также называется IIAD - Interservice Interrogation and Activation Daemon) хранится в JSON-формате в файле "iiad.json", который можно найти по адресу /etc/vmware/ на VCSA или C:\ProgramData\VMware\vCenterServer\cfg\iiad.json на Windows-сервер vCenter:
requestTimeout – дефолтный таймаут для запросов по умолчанию.
hysteresisCount – позволяет отказам постепенно "устаревать" - каждое такое значение счетчика при отказе, число отсчитываемых отказов будет уменьшено на один.
rebootShellCmd – указанная пользователем команда, которая будет исполнена перед перезапуском ВМ.
restartShellCmd – указанная пользователем команда, которая будет исполнена перед перезапуском сервиса.
maxTotalFailures – необходимое число отказов по всем службам, которое должно случиться, чтобы произошел перезапуск виртуальной машины.
needShellOnWin – определяет, нужно ли запускать сервис с параметром shell=True на Windows.
watchdogDisabled – позволяет отключить API Watchdog.
vpxd.watchdogDisabled – позволяет отключить API Watchdog для VPXD.
createSupportBundle – нужно ли создавать support-бандл перед перезапуском сервиса или рестартом ВМ.
automaticServiceRestart – нужно ли перезапускать сервис при обнаружении сбоя или просто записать это в лог.
automaticSystemReboot – нужно ли перезапускать ВМ при обнаружении сбоя или просто записать в лог эту рекомендацию.
Многие из вас знают утилиту esxtop (о которой мы часто пишем), позволяющей осуществлять мониторинг производительности сервера VMware ESXi в различных аспектах - процессорные ресурсы, хранилища и сети. Многие администраторы пользуются ей как раз для того, чтобы решать проблемы производительности.
Но оказывается, что использование esxtop само по себе может тормозить работу сервера VMware ESXi!
Это может произойти в ситуации, если у вас к ESXi смонтировано довольно много логических томов LUN, на обнаружение которых требуется более 5 секунд. Дело в том, что esxtop каждые 5 секунд повторно инициализирует объекты, с которых собирает метрики производительности. В случае с инициализацией LUN, которая занимает длительное время, запросы на инициализацию томов будут складываться в очередь. А как следствие (при большом числе томов) это будет приводить к возрастанию нагрузки на CPU и торможению - как вывода esxtop, так и к замедлению работы сервера в целом.
Выход здесь простой - надо использовать esxtop с параметром -l:
# esxtop -l
В этом случае данная утилита ограничит сбор метрик производительности только теми объектами, которые были обнаружены при первом сканировании. Соответственно, так лучше всего ее и использовать, если у вас к серверу VMware ESXi прицеплено много хранилищ.
Если вы администратор VMware vSphere со стажем, то наверняка попадали в такую ситуацию: по какой-то причине отключается сервер VMware vCenter (он может работать, но не отвечать на подключения), а с ним вместе недоступна и его база (на том же хосте или на отдельном) - и вам нужно искать хост ESXi с этими ВМ, чтобы поднять всю виртуальную инфраструктуру. А хостов ESXi в кластере у вас может быть несколько десятков.
Можно, конечно, сделать правило DRS для vCenter, чтобы он не перемещался по хостам, но в случае срабатывания аварийного восстановления VMware HA, сервер vCenter вполне может поменять хост, так как HA забивает на правила DRS.
В этом случае может оказаться полезным интерфейс PowerCLI, который позволит найти нужную ВМ по ее имени. Но сначала вам нужно разрешить множественные соединения к нескольким хостам. Делается это следующей командой:
Это, конечно, покатит только если у вас на всех хостах ESXi везде одинаковый пароль root. Но если они там разные, то нужно будет для каждого сервера исполнить соответствующую команду.
Далее просто ищем нужную виртуальную машину по ее имени:
(get-vm vCenter01).vmhost
(get-vm SQL01).vmhost
В выводе этих команд будут хосты ESXi, на которых они зарегистрированы. Остается только открыть к ним консоль через vSphere Client и включить эти машины.
Каждый администратор VMware vSphere рано или поздно сталкивается с тем, что хост VMware ESXi выпадает в "Pink Screen of Death" (PSOD - розовый экран смерти):
Причина этого - как правило, аппаратные проблемы сервера (барахлящее оборудование, битые блоки памяти, проблемы с драйверами, в том числе виртуальных устройств, и т.п.). В этом случае полезно погуглить ошибку, но сначала нужно получить дамп ядра (core dump), где сохраняются подробности о причине PSOD.
В VMware vSphere Web Client в представлении Hosts and Clusters нажимаем правой кнопкой на сервере vCenter, далее в контекстном меню выбираем пункт "Export System Logs...":
Далее выбираем интересующий нас хост VMware ESXi:
Затем отчекиваем все галки, кроме CrashDumps:
После экспорта файла открываете его в текстовом редакторе и ищете строчку "@bluescreen":
Ниже вы увидите подробности о произошедшей ошибке:
В данном случае мы видим, что имеет место проблема с драйвером виртуального сетевого адаптера (vNIC) E1000. Можно заменить его на VMXNET3 (как описано в KB 2059053), и проблема уйдет. Ну и прочие подобные ошибки можно гуглить, по PSOD ESXi уже есть много информации на форумах.
Время от времени у пользователей VMware vSphere возникает ошибка, связанная с тем, что виртуальный диск VMDK виртуальной машины оказывается залоченным (то есть эксклюзивно используемым процессом VMX одного из хостов ESXi). В этом случае виртуальная машина не отвечает на попытки включить ее или переместить на другой хост-сервер средствами VMware vMotion. При этом процесс vmx вполне может быть запущен не на том хосте ESXi, на котором машина отображается в VMware vSphere Client или Web Client. Такое может случиться при падении хоста ESXi, массовом отключении питания или неполадках в сети SAN, а также и в некоторых других случаях.
Например, может быть вот такое сообщение об ошибке при включении машины:
Could not power on VM: Lock was not free
Для решения проблемы вам нужно найти хост ESXi, который исполняет vmx-процесс машины, и убить ВМ, которая не отвечает. После этого можно будет использовать VMDK-файл этой машины, а также включить ее, если она не работает.
Делается это следующим образом:
1. Находим хост, исполняющий vmx-процесс виртуальной машины с залоченным VMDK.
Для этого заходим по SSH на один из серверов ESXi (эта процедура работает для версий vSphere 5.5 P05 и 6.0, а также более поздних) и переходим в папку /bin:
#cd /bin
С помощью утилиты vmfsfilelockinfo ищем владельца лока нужного VMDK-файла:
Здесь vm1.vmdk - наш залоченный виртуальный диск, а 192.168.1.10 - IP-адрес сервера VMware vCenter. Вам потребуется ввести пароль его администратора.
Вывод будет примерно таким:
vmfsflelockinfo Version 1.0
Looking for lock owners on "VM1_1-000001-delta.vmdk"
"VM1_1-000001-delta.vmdk" is locked in Exclusive mode by host having mac address ['00:50:56:03:3e:f1']
Trying to make use of Fault Domain Manager
----------------------------------------------------------------------
Found 0 ESX hosts using Fault Domain Manager.
----------------------------------------------------------------------
Could not get information from Fault domain manager
Connecting to 192.168.1.10 with user administrator@vsphere.local
Password: xXxXxXxXxXx
----------------------------------------------------------------------
Found 3 ESX hosts from Virtual Center Server.
----------------------------------------------------------------------
Searching on Host 192.168.1.178
Searching on Host 192.168.1.179
Searching on Host 192.168.1.180
MAC Address : 00:50:56:03:3e:f1
Host owning the lock on the vmdk is 192.168.1.180, lockMode : Exclusive
Total time taken : 0.27 seconds.
Из вывода можно понять 2 важные вещи:
MAC-адрес хоста, залочившего VMDK
IP-адрес хоста, залочившего VMDK
Тип лока - Exclusive
Кстати, лок может быть нескольких типов:
mode 0 - нет лока
mode 1 - эксклюзивный лок (vmx-процесс машины существует и использует VMDK-диск)
mode 2 - лок только для чтения (например, для основного диска, в случае если у него есть снапшоты)
mode 3 - лок для одновременной записи с нескольких хостов (например, для кластеров MSCS или ВМ, защищенных технологией VMware Fault Tolerance).
2. Точно определяем хост, машина которого держит VMDK.
Если IP-адрес показан - хост определен. Если, мало ли, по какой-то причине его нет, можно ориентироваться на MAC-адрес. Выяснить его можно следующей командой на хосте ESXi:
# vim-cmd hostsvc/net/info | grep "mac ="
3. Обнаруживаем процесс VMX, который держит VMDK.
Выполняем на найденном ESXi команду:
# lsof | egrep 'Cartel|vm1.vmdk'
Получаем что-то вроде этого:
Cartel | World name | Type | fd | Description
36202 vmx FILE 80 /vmfs/volumes/556ce175-7f7bed3f-eb72-000c2998c47d/VM1/vm1.vmdk
Мы нашли Cartel ID нужного процесса VMX (36202). Теперь выполняем команду, чтобы найти ее World ID:
# esxcli vm process list
Получаем такой вывод:
Alternate_VM27
World ID: 36205
Process ID: 0
VMX Cartel ID: 36202
UUID: 56 4d bd a1 1d 10 98 0f-c1 41 85 ea a9 dc 9f bf
Display Name: Alternate_VM27
Config File: /vmfs/volumes/556ce175-7f7bed3f-eb72-000c2998c47d/Alternate_VM27/Alternate_VM27.vmx
Alternate_VM20
World ID: 36207
Process ID: 0
VMX Cartel ID: 36206
UUID: 56 4d bd a1 1d 10 98 0f-c1 41 85 ea a5 dc 94 5f
Display Name: Alternate_VM20
Config File: /vmfs/volumes/556ce175-7f7bed3f-eb72-000c2998c47d/Alternate_VM20/Alternate_VM20.vmx
...
Видим, что World ID нашей машины - 36205.
4. Убиваем VMX-процесс, залочивший VMDK.
Ну и убиваем зависший процесс VMX следующей командой:
# esxcli vm process kill --type force --world-id <ID>
После этого с машиной и ее диском можно делать уже что требуется.
Также для более ранних версий VMware vSphere посмотрите нашу статью вот здесь.
На днях компания Citrix обновила свою утилиту Receiver Diagnostics Tool до версии 1.1. Эта утилита позволяет администраторам решений Citrix XenDesktop и XenApp собрать с рабочих ПК пользователей необходимую диагностическую информацию, касающуюся работы клиента Citrix Receiver и окружения. В частности, это информация о конфигурации систем, а также различного рода логи, которые позволят вам узнать о причинах ошибки.
Возможности Citrix Receiver Diagnostics Tool v1.1:
Упрощенная активация и настройка работы механизма Citrix Diagnostic Facility (CDF)
Сбор информации в один клик о:
Системе на пользовательском ПК
Конфигурации Receiver
Логах Application и System Events
Результатах вывода Microsoft DxDiag Tool
Логах Always-On
Логах, созданных при инсталляции
Возможность упаковки и отправки диагностических данных в на сторону сервиса Citrix CIS (далее через MyCitrix можно получить поддержку)
Утилита очень полезна, когда у пользователя что-то не работает, а вы не можете понять что.
Как пользоваться утилитой:
Скачать и запустить
Нажать Start Receiver Tracing
Затем надо воспроизвести проблемную ситуацию
Далее жмем
Stop Receiver Tracing и нажимаем Collect & Upload, если хотим отправить данные на сторону CIS, либо жмем Save, чтобы сохранить данные у себя.
Скачать Citrix Receiver Diagnostics Tool v1.1 можно по этой ссылке.
Рано или поздно любой администратор VMware vSphere сталкивается с проблемой разросшихся тонких дисков виртуальных машин, которые увеличиваются неизбежно по своей природе (при удалении файлов в гостевой ОС блоки не обнуляются и не отдаются обратно на хранилище с уменьшением VMDK).
Но, во-первых, SVMotion есть не у всех (так как в начальные издания vSphere эта технология не входит), а, во-вторых, есть более простой способ. Итак:
1. Давайте сначала "раздуем" исходный тонкий диск с помощью утилиты sdelete.
Было (18,74 ГБ):
Запускаем в гостевой ОС Windows утилиту:
sdelete -c
Стало (41,8 ГБ):
2. Очищаем удаленные блоки в гостевой ОС, заполняя их нулями.
Для этого запустим команду:
sdelete -z
3. Уменьшаем размер виртуального диска с помощью утилиты vmkfstools.
Делается это с помощью ключа -K (можно также использовать ключ --punchzero) в консоли сервера ESXi:
vmkfstools -K Test.vmdk
Вот и все, смотрим на получившийся размер:
Надо отметить, что утилита vmkfstools, запущенная с ключом -K, еще и может преобразовать обычный диск (zeroedthick или eagerzeroedthick) в thin disk с вычищением нулевых блоков и, соответственно, уменьшением размера vmdk.
Мы уже упоминали компанию opvizor на нашем сайте - она тогда называлась еще Icomasoft. Она время от времени делает утилитки для виртуальной инфраструктуры. Оказалось у нее есть могущая оказаться полезной многим утилита Snapwatcher Enterprise Edition.
Как знают администраторы VMware vSphere, снапшоты виртуальных машин в большой виртуальной инфраструктуре - это просто беда. Они плодятся неаккуратными пользователями и администраторами, создаются пачками в тестовых системах и почему-то иногда не удаляются средствами резервного копирования. Для решения таких проблем и предлагается использовать Snapwatcher:
Что умеет Snapwatcher:
Отслеживание имеющихся снапшотов ВМ на различных vCenter.
Отчет о количестве паразитно занятого снапшотами дискового пространства.
Нахождение некорректных снапшотов (например, после средств бэкапа).
Удаление ненужных снапшотов централизованно, из одной консоли.
Починка невалидных снапшотов (очевидно, работает не всегда - но весьма интересная функция).
Отслеживание истории снапшотов.
Как это работает:
Сам продукт Snapwatcher платный ($200 за лицензию на пользователя), но у него есть триальная версия. А так как в большинстве случаев проблема со снапшотами в виртуальной среде - разовая, то можно скачать Snapwatcher бесплатно и все пофиксить.
Ниже приведем ссылки на статьи VMware Knowledge Base (взято отсюда), где можно узнать о расположении и назначении файлов журнала (логов) для различных продуктов, включая компоненты решения VMware vSphere.
Вчера мы писали про анонсированный в рамках VMworld Europe 2014 пакет продуктов VMware vRealize Operation Management Suite 6.0, который содержит в себе множество решений семейства vRealize. Один из таких продуктов - VMware vRealize Log Insight 2.5 был также обновлен на VMworld и анонсирован к выпуску в конце 2014 года (у него очень бодрый темп обновлений). После проведенного ребрендинга продуктов, Log Insight - это часть большого семейства vRealize.
Напомним, что решение Log Insight предназначено для автоматизированного управления файлами журналов, а также сбора различных данных, их анализа и поиска. Кстати, о прошлой версии VMware Log Insight 2.0 мы писали вот тут.
Поработать с решением Log Insight можно и не устанавливая его, для этого можно выполнить одну из лабораторных работ:
Основные новые возможности VMware vRealize Log Insight 2.5:
Доступ на базе ролей (Role Based Access Control).
Интеграция инвентори продукта с решением vCenter Operations Management Suite (про это мы немного писали тут).
Внутренний балансировщик для масштабирования нагрузки.
Расшираение пакета Universal Collection Framework for Linux.
Интернационализация и локализация на основные языки (напомним, что русский к ним не относится).
Режим представления дэшборда, в котором все изменяется в режиме реального времени.
На специальном портале Content Pack Marketplace можно найти десятки модулей интеграции Log Insight со сторонним программным обеспечением:
Скачать новую версию VMware vRealize Log Insight 2.5 пока нельзя, но можно зарегистрироваться для оповещения о доступности по этой ссылке.
Те из вас, кто много всего устанавливает в своей тестовой лаборатории или продакшен-среде VMware vSphere, наверное рано или поздно сталкиваются с тем, что vSphere Web Client очень медленно грузится (иногда по 2-3 минуты) или тормозит при работе в нем.
Одна из возможных причин тормозов - наличие установленных плагинов, которые может быть вам уже и не нужны, а отъедают системные ресурсы.
Поэтому иногда целесообразно удалить их. Идем в Managed Object Browser (MOB) на сервере vCenter, для чего переходим в браузере по такой ссылке:
http://<vcenter_name_or_IP>/mob
Далее после аутентификации переходим в раздел "content" (здесь и далее необходимые ссылки подсвечены желтым):
Затем переходим в раздел ExtensionManager:
Там нам нужно найти соответствующий плагин для удаления. Вот таблица всех плагинов VMware, которые могут быть подцеплены к Web Client:
Например, нам надо из vSphere Client удалить плагин vSphere Data Protection, находим его (записываем - все, что в квадратных скобках без кавычек) и проваливаемся дальше:
Вызываем для него метод UnregisterExtension:
В качестве значения при вызове метода указываем имя плагина, например, "com.vmware.vdp":
После успешного вызова метода он должен возвратить результат "void":
Таким вот нехитрым способом можно удалить все лишние плагины с сервера, где установлен vSphere Web Client, после чего последний станет значительно быстрее запускаться.
Компания VMware выпустила интересный и полезный документ в виде таблицы - Virtual SAN 5.5 Validation Guide. Он позволяет решать проблемы, возникшие в кластерах хранилищ VSAN, как на стадии пре-инсталляции, так и после развертывания решения.
Изначально эту таблицу использовали сотрудники технической поддержки VMware для решения проблем, возникающих в среде Virtual SAN, но потом его было решено выпустить публично в целях стимуляции самоподдержки пользователей.
Документ составлен техническими специалистами VMware для своих нужд, поэтому там так предельно много конкретики, что очень полезно администраторам VMware vSphere в повседневной работе.
В первой части рассматриваются засады, которые может получить пользователь при развертывании кластера Virtual SAN, в во второй уже приводятся ситуации, которые могут возникнуть после инсталляции и в процессе эксплуатации решения.
При этом (где это возможно) приводятся шаги vCenter Web Client или сценарии CLI (RVC, ESXCLI, PowerCLI), которые позволят идентифицировать и ликвидировать проблему. Документ живет и постоянно обновляется, поэтому можно периодически заглядывать - не обновилась ли его версия (сейчас это 2.1).
Также очень рекомендуют в целях траблшутинга обращаться к инструменту vSphere Ruby Console (RVC), который позволяет автоматизировать множество задач. Полезные ссылки:
Помимо всего прочего, в документе рассматривается способ получения информации о структуре и содержимом кэша vFRC. Сделать это можно с помощью команды:
~ # esxcli storage vflash cache list
Эта команда выведет список идентификаторов кэша для VMDK-дисков, для которых включена vFRC. Далее с помощью следующей команды можно узнать детали конкретного ID кэша:
# esxcli storage vflash cache get –c <cache-identifier>
Несколько больше информации (включая объем закэшированных данных) можно почерпнуть из команд, приведенных ниже. Для этого потребуется создать переменную CacheID:
~ # cacheID='vsish -e ls /vmkModules/vflash/module/vfc/cache/'
~ # vsish -e get /vmkModules/vflash/module/vfc/cache/${cacheID}stats
В результате будет выведено что-то подобное:
vFlash per cache instance statistics {
cacheBlockSize:8192
numBlocks:1270976
numBlocksCurrentlyCached:222255
numFailedPrimaryIOs:0
numFailedCacheIOs:0
avgNumBlocksOnCache:172494
read:vFlash per I/O type Statistics {
numIOs:168016
avgNumIOPs:61
maxNumIOPs:1969
avgNumKBs:42143
maxNumKBs:227891
avgLatencyUS:16201
maxLatencyUS:41070
numPrimaryIOs:11442
numCacheIOs:156574
avgCacheLatencyUS:17130
avgPrimaryLatencyUS:239961
cacheHitPercentage:94
}
write:vFlash per I/O type Statistics {
numIOs:102264
avgNumIOPs:307
maxNumIOPs:3982
avgNumKBs:10424
maxNumKBs:12106
avgLatencyUS:3248
maxLatencyUS:31798
numPrimaryIOs:102264
numCacheIOs:0
avgCacheLatencyUS:0
avgPrimaryLatencyUS:3248
cacheHitPercentage:0
}
rwTotal:vFlash per I/O type Statistics {
numIOs:270280
avgNumIOPs:88
maxNumIOPs:2027
avgNumKBs:52568
maxNumKBs:233584
avgLatencyUS:11300
maxLatencyUS:40029
numPrimaryIOs:113706
numCacheIOs:156574
avgCacheLatencyUS:17130
avgPrimaryLatencyUS:27068
cacheHitPercentage:58
}
flush:vFlash per operation type statistics {
lastOpTimeUS:0
numBlocksLastOp:0
nextOpTimeUS:0
numBlocksNextOp:0
avgNumBlocksPerOp:0
}
evict:vFlash per operation type statistics {
lastOpTimeUS:0
numBlocksLastOp:0
nextOpTimeUS:0
numBlocksNextOp:0
avgNumBlocksPerOp:0
}
}
Приведенный вывод содержит все метрики, означенные в упомянутом документе. Далее вы можете использовать эту информацию для принятия решения о размере кэша на серверах ESXi и значении других настроек, описанных в документе.
Многие из вас знают о компании Login Consultants, которая занимается тестированием гипервизоров и ПО для виртуализации настольных ПК. Она делает хорошие сравнения в виде технических документов, а также наглядных демонстраций. Выпускаемый компанией инструмент VSI (Virtual Session Indexer) для симуляции нагрузки и тестирования VDI-сред стал стандартом де-факто при тестировании инфраструктуры виртуальных ПК у различных вендоров (например, см. тут). Напомним, что это коммерческое решение, а для бесплатного использования доступен продукт VSI Express.
Напомним, что средство Login VSI является вендоронезависимым, поэтому с его помощью можно тестировать любое VDI-решение, которое есть сегодня на рынке.
Итак, что нового:
1. Появилось 4 новых типа пользовательских нагрузок:
Task
Office (1vCPU)
Knowledge (2vCPU)
Power user
Можно создать и свой собственный профиль нагрузки на базе ваших корпоративных приложений.
2. Улучшения компонента Login VSI Analyzer.
Теперь это средство может собирать данные через VMware esxtop и Microsoft Windows Performance Monitor (есть возможность объединения данных от разных источников), обрабатывать их и делать выводы об "узких местах" VDI-инфраструктуры.
Работает это так: например, у вас есть график, где по горизонтали отложено количество виртуальных ПК на сервер ESXi, а по вертикали - время отклика. Провели два теста для нагрузки на ПК с ОС Windows 7 и Microsoft Office 2010 на борту. В одном тесте для достижения трэшхолда по отклику удалось разместить 148 сессий пользователей, а вот в другом - только 112 (кликабельно).
Надо выяснить, в чем дело - почему теперь на сервере помещается меньше пользователей? Накладываем график загрузки CPU и дисков и видим, что загрузка процессора достигает 100%, когда число пользователей переваливает за границу 112.
Таким образом, Virtual Session Indexer 4.1 позволяет не только получать информацию о производительности своей VDI-инфраструктуры, но и решать подобного рода проблемы, а также отвечать на вопрос, где ресурсов не хватает, а где наоборот переизбыток.
Скачать Login VSI 4.1 можно по этой ссылке. Если у вас уже есть версия 4.0, то вы просто можете скачать патч. Скриншоты продукта можно скачать тут.
Многие начинающие администраторы VMware vSphere задаются вопросом, как правильно установить время на хосте VMware ESXi. Те из них, кто привык делать это в ОС Linux, могут попробовать выполнить команду:
~ # date -s
Однако будет вот такой результат:
date: option requires an argument -- s BusyBox v1.19.0 (2012-02-29 14:20:08 PST) multi-call binary. Usage: date [OPTIONS] [+FMT] [TIME] Display time (using +FMT), or set time
[-s,--set] TIME Set time to TIME -u,--utc Work in UTC (don't convert to local time) -R,--rfc-2822 Output RFC-2822 compliant date string -I[SPEC] Output ISO-8601 compliant date string SPEC='date' (default) for date only, 'hours', 'minutes', or 'seconds' for date and time to the indicated precision -r,--reference FILE Display last modification time of FILE -d,--date TIME Display TIME, not 'now' -D FMT Use FMT for -d TIME conversion
Recognized TIME formats: hh:mm[:ss] [YYYY.]MM.DD-hh:mm[:ss] YYYY-MM-DD hh:mm[:ss] [[[[[YY]YY]MM]DD]hh]mm[.ss]
~ # date -s 2014-07-12 12:00:00 date: Setting date not supported; use <esxcli system time set>
Обратим внимание на последнюю строчку, которая говорит нам о том, что команда date не поддерживается для установки даты и времени, вместо нее нужно использовать утилиту esxcli. Выполняем указанную команду:
~ # esxcli system time set You must specify one of year, month, day, hour, minute or second
Вызовем помощь:
~ # esxcli system time set --help
Usage: esxcli system time set [cmd options]
Description:
set Set the system clock time. Any missing parameters will default to the current time
Cmd options:
-d|--day=<long> Day
-H|--hour=<long> Hour
-m|--min=<long> Minute
-M|--month=<long> Month
-s|--sec=<long> Second
-y|--year=<long> Year
Теперь все стало ясно: чтобы установить, например, октябрь месяц, вызываем команду с параметром "-M 10", то есть:
~ # esxcli system time set -M 10
Проверяем, что октябрь установился:
~ # date
Mon Oct 12 10:43:52 UTC 2014
Аналогично устанавливаем год, день, часы и минуты, используя параметры -y, -d, -H, -m, соответственно.
Ну а проверить можно не только с помощью date, но и через esxcli, заменив set на get:
Бывает такое, что пользователь системы жалуется администратору виртуальной инфраструктуры VMware vSphere, что у него пропал сетевой адаптер в виртуальной машине, и она больше недоступна из внешней сети. Администратор смотрит в лог виртуальной машины (vmware-##.log) и видит там вот такое:
Mar 15 03:13:37.463: vmx| Powering off Ethernet1
Mar 15 03:13:37.463: vmx| Hot removal done.
Это, как вы уже догадались, означает, что кто-то тыкнул на иконку "Safely Remove Hardware" в гостевой ОС и выбрал там сетевой адаптер ВМ:
Либо это было сделано случайно в vSphere Client или Web Client. Поправить это легко - надо отключить функции Hot Add для виртуальной машины.
Для этого:
Соединяемся с хостом ESXi/ESX напрямую или через vCenter Server посредством vSphere Client.
Выключаем виртуальную машину.
Выбираем для нее Edit Settings и переходим на вкладку Options.
Выбираем General > Configuration Parameters > Add Row.
Добавляем строчку с именем devices.hotplug и значением false.
Включаем виртуальную машину.
После этого при попытке удаления устройства работающей виртуальной машины будет выдано такое сообщение
Если же вы не хотите запрещать Hot Add для всех устройств, а хотите просто спрятать возможность удаления сетевой карты из Safely Remove Hardware, то нужно сделать следующее:
Запустить редактор реестра как Local System. Для этого можно использовать утилиту psexec Tool.
Выполняем psexec -i -s regedit.exe.
Идем в ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum ищем наш драйвер NIC (в его названии есть VMXNET3, E1000 и т.п.).
Установите значение ключа Capabilities на 4 единицы ниже.
Например, вот тут мы видим значение ключа 16:
Устанавливаем его на 4 меньше, то есть в значение 12:
После этого сетевой адаптер исчезнет из безопасного удаления устройств:
Не так давно мы писали о том, что была выпущена новая версия решения VMware Log Insight 2.0, предназначенного для автоматизированного управления файлами журналов, а также сбора различных данных, их анализа и поиска. На днях компания VMware выпустила для него Windows Content Pack, который позволяет получать информацию о состоянии Windows-систем и их приложений.
Данный контент-пак покрывает множество аспектов работы Windows-систем, которые представлены в категориях General, System, Application и Security. Представления включают в себя 10 групп дэшбордов, 52 виджета, 6 алертов и 41 получаемое поле данных.
Скачать Windows Content Pack для VMware Log Insight можно по этой ссылке.
Интересную особенность тут обнаружил один из читателей Дукана Эппинга: оказывается в VMware vSphere 5.5 Update 1 при перезапуске/выключении хоста VMware ESXi через консоль DCUI рестарта его виртуальных машин посредством механизма VMware HA не происходит.
Ну то есть, если выключение ESXi делать по клавише <F12> в консоли сервера:
Действительно, в этом случае в логе FDM можно увидеть вот такую запись:
2014-04-04T11:41:54.882Z [688C2B70 info 'Invt' opID=SWI-24c018b] [VmStateChange::SavePowerChange] vm /vmfs/volumes/4ece24c4-3f1ca80e-9cd8-984be1047b14/New Virtual Machine/New Virtual Machine.vmx curPwrState=unknown curPowerOnCount=0 newPwrState=powered off clnPwrOff=true hostReporting=host-113
Это означает, что VMware vSphere считает, что виртуальные машины были выключены корректно (администратором/хостом), а значит их перезапуск механизмом VMware HA не требуется (параметр clnPwrOff=true).
Совсем другая картина, если мы делаем ребут или выключение VMware ESXi из VMware vSphere Client или vSphere Web Client:
В этом случае в логе FDM мы обнаружим что-то вроде такого:
2014-04-04T12:12:06.515Z [68040B70 info 'Invt' opID=SWI-1aad525b] [VmStateChange::SavePowerChange] vm /vmfs/volumes/4ece24c4-3f1ca80e-9cd8-984be1047b14/New Virtual Machine/New Virtual Machine.vmx curPwrState=unknown curPowerOnCount=0 newPwrState=powered on clnPwrOff=false hostReporting=host-113
Здесь уже мы видим, что clnPwrOff=false, а значит vSphere полагает, что что-то пошло не так и VMware HA перезапустит виртуальные машины "отказавшего" хоста.
Это поведение актуально для VMware vSphere 5.5 Update 1, но пользователи в комментариях к статье Дункана отмечают, что подобное поведение наблюдается и для vSphere 5.0. Поэтому будет не лишним знать об этом всем тем, кто после настройки отказоустойчивого кластера VMware HA тестирует его работоспособность путем перезагрузки хостов ESXi.
Таги: VMware, vSphere, HA, VMachines, ESXi, DCUI, Troubleshooting
Некоторые администраторы (которые, например, используют контроллер домена как единую точку руления инфрастуктурой) были удивлены, что с выходом VMware vSphere 5.5 толстый C#-клиент vSphere Client отказывается устанавливаться на контроллере Active Directory. При попытке такой установки будет показана ошибка:
vSphere Client requires Windows XP SP2 or later.
vSphere Client cannot be installed on a Domain Controller.
Все это от того, что у Microsoft есть стандарт о том, что на контроллере домена не должно быть установлено никакого дополнительного ПО, не относящегося к функциям AD. И VMware вынуждена ему подчиняться. Хотя это и не логично - не всем нужна отдельная машина в небольшой инфраструктуре чисто под управление VMware vSphere.
Ограничение обходится просто. Запускаем установщик клиента с параметром обхода проверок:
VMware-viclient.exe /v "SKIP_OS_CHECKS=1"
Второй вариант - использовать на контроллере домена виртуализованный с помощью ThinApp толстый клиент (ThinApped vSphere Client), о котором мы уже писали тут.
Но его придется создать самостоятельно - актуальная версия поддерживаемой сейчас платформы - vSphere 5.0. Хотя есть кастомные версии и для 5.1.
Некоторое время назад компания VMware выпустила полезную утилиту VMware vSphere Mobile Watchlist, которая позволяет мониторить виртуальную инфраструктуру с телефона на Android и iOS / iPhone, а также своевременно обнаруживать и решать проблемы, например, с пляжа, когда у вас нет под рукой даже планшета.
vSphere Mobile Watchlist предназначен для трех простых вещей:
Посмотреть на инфраструктуру и обнаружить проблему.
Попытаться ее исправить, перезагрузив ВМ или хосты.
Если не помогло - сообщить о проблеме персоналу своей компании, который, в отличе от вас, находится на работе.
В качестве платформы, чтобы работал vSphere Mobile Watchlist, должна использоваться VMware vSphere 5.0 или более поздняя версия.
Основные возможности vSphere Mobile Watchlist:
Создание списка ВМ для мониторинга (собственно, Watchlist) - несколько машин из инвентори, которые будут отслеживаться. Можно создавать несколько списков.
Просмотр состояния ВМ - статус (включена/выключена), жизнедеятельность, консоль (удобно для того, чтобы узнать, не появилось ли синего экрана или сообщений об ошибках) и связанные объекты. Также доступны показатели загрузки процессора, памяти и места на диске.
Получение в случае сбоя ВМ сообщения об ошибке в виде алерта, к которому прилагается не только описание сути проблемы, но и ссылка на соответствующую статью KB.
Операции по изменению состояния ВМ - Start/Stop/Suspend/Reboot (в том числе "мягкие" Shudown и Restart).
Возможность сообщить о проблеме (вместе со статьей KB) своим коллегам.
Требования к смартфонам/планшетам:
iOS 7.0 или более поздняя. Подерживается iPhone, iPad, iPod Touch
Android 4.0.3 или более поздняя
Скачать VMware vSphere Mobile Watchlist можно по этим ссылкам:
Для iOS
Для Android
Комьюнити по продукту доступно по этой ссылке. В общем-то, это очередная погремушка, но в экстренном случае она может оказаться кому-то полезной.
Попросту говоря, это мощный поиск по логам и их визуализатор, который используется для поиска причин проблем в виртуальной инфраструктуре (root cause analysis):
Напомним, что о возможностях VMware vCenter Log Insight 1.0 мы уже писали вот тут, кроме него доступны также Partner Content Packs от различных партнеров VMware (можно парсить и визуализировать логи, например, от хранилищ NetApp или EMC).
Основные новые возможности VMware vCenter Log Insight 1.5:
Управление контентом
Улучшенный раздел Content Packs
Возможность импорта content pack в окружение пользователя, что позволяет ему их изменять
Возможность изменять поля запросов/виджетов, сохранять и обновлять их по требованию
Функции по реорганизации контента
Так выглядит контент-пак для VMware vSphere:
Импорт контент-пака с возможностью изменения набора компонентов:
Добавление виджета с запросом на дэшборд:
Возможности администрирования VMware vCenter Log Insight 1.5
Страница Health заменена более функциональной страницей Resources
Новое представление Appliance с возможностью обновить виртуальный модуль через веб-интерфейс
Поддержка Active Directory
Скрипт Configure-esxi теперь есть в графическом интерфейсе
Лайв-графики со вкладки Resources:
Поддержка служб Active Directory:
Запуск скрипта Configure-esxi для сбора логов:
Другие улучшения VMware vCenter Log Insight 1.5
Функция сбора уникальных событий за определенное время
Улучшенное кэширование данных, что существенно повышает производительность
Ограничения вывода результатов - теперь можно задавать условие (например, не содержит какой-либо текст), в целях эффективной фильтрации
Новое представление Field Table в результатах поиска для получения детальной информации о событии, которое отражает запись в логе
Уникальные события - хосты, имевшие доступ к Log Insight:
Ограничитель результатов вывода (они применяются динамически):
Представление Field Table:
Публичную бету VMware vCenter Log Insight 1.5 можно скачать по этой ссылке. Релизную версию VMware обещает выпустить в середине декабря 2013 года.
Таги: VMware, Center, Log Insight, Beta, Update, Troubleshooting
Не так давно мы писали о средстве для анализа логов VMware vSphere - VMware vCenter Log Insight, которое было выпущено совсем недавно (пока еще в бета-версии). Продукт поставляется в виде виртуального модуля (Virtual Appliance), который развертывается как обычный OVF-пакет, после чего становится доступен сбор и анализ данных syslog с серверов VMware ESXi 4.1, 5.0, 5.1, а также vCenter Server Appliance и других источников. Кроме того, Log Insight может быть интегрирован с vCenter Operations Manager.
Благодаря усилиям партнеров VMware, а именно CISCO, EMC, HyTrust, NetApp, NetFlow Logic, Puppet Labs и VCE, стали доступны Partner Content Packs для VMware vCenter Log Insight.
Концепция контент-пака такова: вы загружаете Content Pack в Log Insight, после чего вы получаете набор дэшбордов, сохраненных запросов, алертов и описаний различных полей для анализа файлов журналов. По умолчанию вместе с Log Insight идет vSphere Content Pack, который избавит от необходимости знать тонкости debug-сообщений и различные параметры вывода логов серверов VMware ESXi. Все станет проще и понятней.
Более подробная информация о продукте VMware vCenter Log Insight доступна на специальном портале.
Несомненно, список этих контент-паков будет расти, что вполне может сделать vCenter Log Isight основным средством анализа логов в ИТ-инфраструктуре предприятий.
RSS
